home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc1293 < prev    next >
Encoding:
Text File  |  1992-01-16  |  11.1 KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         T. Bradley
  8. Request for Comments: 1293                                      C. Brown
  9.                                           Wellfleet Communications, Inc.
  10.                                                             January 1992
  11.  
  12.                   Inverse Address Resolution Protocol
  13.  
  14. 1.  Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. 2.  Abstract
  23.  
  24.    This memo describes additions to ARP that will allow a station to
  25.    request a protocol address corresponding to a given hardware address.
  26.    Specifically, this applies to Frame Relay stations that may have a
  27.    Data Link Connection Identifier (DLCI), the Frame Relay equivalent of
  28.    a hardware address, associated with an established Permanent Virtual
  29.    Circuit (PVC), but do not know the protocol address of the station on
  30.    the other side of this connection.  It will also apply to other
  31.    networks with similar circumstances.
  32.  
  33. 3.  Conventions
  34.  
  35.    The following language conventions are used in the items of
  36.    specification in this document:
  37.  
  38.      o Must, Will, Shall or Mandatory -- the item is an absolute
  39.        requirement of the specification.
  40.  
  41.      o Should or Recommended -- the item should generally be
  42.        followed for all but exceptional circumstances.
  43.  
  44.      o May or Optional -- the item is truly optional and may be
  45.        followed or ignored according to the needs of the
  46.        implementor.
  47.  
  48. 4.  Introduction
  49.  
  50.    This document will rely heavily on Frame Relay as an example of how
  51.    the Inverse Address Resolution Protocol (InARP) can be useful. It is
  52.    not, however, intended that InARP be used exclusively with Frame
  53.    Relay.  InARP may be used in any network that provides destination
  54.    hardware addresses without indicating corresponding protocol
  55.  
  56.  
  57.  
  58. Bradley, Brown                                                  [Page 1]
  59.  
  60. RFC 1293                      Inverse ARP                   January 1992
  61.  
  62.  
  63.    addresses.
  64.  
  65. 5.  Motivation
  66.  
  67.    The motivation for the development of Inverse ARP is a result of the
  68.    desire to make dynamic address resolution within Frame Relay both
  69.    possible and efficient.  Permanent virtual circuits (PVCs) and
  70.    eventually switched virtual circuits (SVCs) are identified by a Data
  71.    Link Connection Identifier (DLCI).  These DLCIs define a single
  72.    virtual connection through the wide area network (WAN) and are the
  73.    Frame Relay equivalent to a hardware address.  Periodically, through
  74.    the exchange of signalling messages, a network may announce a new
  75.    virtual circuit with its corresponding DLCI.  Unfortunately, protocol
  76.    addressing is not included in the announcement.  The station
  77.    receiving such an indication will learn of the new connection, but
  78.    will not be able to address the other side.  Without a new
  79.    configuration or mechanism for discovering the protocol address of
  80.    the other side, this new virtual circuit is unusable.
  81.  
  82.    Other resolution methods were considered to solve the problems, but
  83.    were rejected.  Reverse ARP [4], for example, seemed like a good
  84.    candidate, but the response to a request is the protocol address of
  85.    the requesting station not the station receiving the request as we
  86.    wanted.  IP specific mechanisms were limiting since we wished to
  87.    allow protocol address resolution of many protocols.  For this
  88.    reason, we expanded the ARP protocol.
  89.  
  90.    Inverse Address Resolution Protocol (InARP) will allow a Frame Relay
  91.    station to discover the protocol address of a station associated with
  92.    the virtual circuit.  It is more efficiently than simulating a
  93.    broadcast with multiple copies of the same message and it is more
  94.    flexible than relying on static configuration.
  95.  
  96. 6.  Packet Format
  97.  
  98.    Inverse ARP is an extension of the existing ARP.  Therefore, it has
  99.    the same format as standard ARP.
  100.  
  101.       ar$hrd   16 bits         Hardware type
  102.       ar$pro   16 bits         Protocol type
  103.       ar$hln    8 bits         Byte length of each hardware address (n)
  104.       ar$pln    8 bits         Byte length of each protocol address (m)
  105.       ar$op    16 bits         Operation code
  106.       ar$sha    nbytes         source hardware address
  107.       ar$spa    mbytes         source protocol address
  108.       ar$tha    nbytes         target hardware address
  109.       ar$tpa    mbytes         target protocol address
  110.  
  111.  
  112.  
  113.  
  114. Bradley, Brown                                                  [Page 2]
  115.  
  116. RFC 1293                      Inverse ARP                   January 1992
  117.  
  118.  
  119.    Possible values for hardware and protocol types are the same as those
  120.    for ARP and may be found in the current Assigned Numbers RFC [2].
  121.  
  122.    Length of the hardware and protocol address are dependent on the
  123.    environment in which InARP is running.  For example, if IP is running
  124.    over Frame Relay, the hardware address length is between 2 and 4, and
  125.    the protocol address length is 4.
  126.  
  127.    The operation code indicates the type of message, request or reply.
  128.  
  129.       InARP request  = 8
  130.       InARP reply = 9
  131.  
  132.    These values were chosen so as not to conflict with other ARP
  133.    extensions.
  134.  
  135. 7.  Protocol Operation
  136.  
  137.    Basic InARP operates essentially the same as ARP with the exception
  138.    that InARP does not broadcast requests.  This is because the hardware
  139.    address of the destination station is already known. A requesting
  140.    station simply formats a request by inserting its source hardware and
  141.    protocol addresses and the known target hardware address.  It then
  142.    zero fills the target protocol address field.  Finally, it will
  143.    encapsulate the packet for the specific network and send it directly
  144.    to the target station.
  145.  
  146.    Upon receiving an InARP request, a station may put the requester's
  147.    protocol address/hardware address mapping into its ARP cache as it
  148.    would any ARP request.  Unlike other ARP requests, however, the
  149.    receiving station may assume that any InARP request it receives is
  150.    destined for it. For every InARP request, the receiving station may
  151.    format a proper reply using the source addresses from the request as
  152.    the target addresses of the reply.  If the station is unable or
  153.    unwilling to reply, it ignores the request.
  154.  
  155.    When the requesting station receives the InARP reply, it may complete
  156.    the ARP table entry and use the provided address information.  Note:
  157.    as with ARP, information learned via InARP may be aged or invalidated
  158.    under certain circumstances.
  159.  
  160. 7.1.  Operation with Multi-Addressed Hosts
  161.  
  162.    In the context of this discussion, a Multi-Addressed host will refer
  163.    to a host that has multiple protocol addresses assigned to a single
  164.    interface.  If such a station receives an InARP request, it must
  165.    choose one address with which to respond. To make such a selection,
  166.    the receiving station must first look at the protocol address of the
  167.  
  168.  
  169.  
  170. Bradley, Brown                                                  [Page 3]
  171.  
  172. RFC 1293                      Inverse ARP                   January 1992
  173.  
  174.  
  175.    requesting station, and then respond with the protocol address
  176.    corresponding to the network of the requester.  For example, if the
  177.    requesting station is probing for an IP address, the responding
  178.    multi-addressed station should respond with an IP address which
  179.    corresponds to the same subnet as the requesting station.  If the
  180.    station does not have an address that is appropriate for the request
  181.    it should not respond.  In the IP example, if the receiving station
  182.    does not have an IP address assigned to the interface that is a part
  183.    of the requested subnet, the receiving station would not respond.
  184.  
  185.    A multi-addressed host may choose to send an InARP request for each
  186.    of the addresses defined for the given interface.  It should be
  187.    noted, however, that the receiving side may answer some or none of
  188.    the requests depending on its configuration.
  189.  
  190. 7.2.  Protocol Operation Within Frame Relay
  191.  
  192.    One case where Inverse ARP can be used is when a new virtual circuit
  193.    is signalled.  The Frame Relay station may format an InARP request
  194.    addressed to the new virtual circuit.  If the other side supports
  195.    InARP, it may return a reply indicating the protocol address
  196.    requested.
  197.  
  198.    The format for an InARP request is a follows:
  199.  
  200.       ar$hrd - 0x000F the value assigned to Frame Relay
  201.       ar$pro - protocol type for which you are searching
  202.                   (i.e.  IP = 0x0800)
  203.       ar$hln - 2,3, or 4 byte addressing length
  204.       ar$pln - byte length of protocol address for which you
  205.                   are searching (for IP = 4)
  206.       ar$op  - 8; InARP request
  207.       ar$sha - Q.922 address of requesting station
  208.       ar$spa - protocol address of requesting station
  209.       ar$tha - Q.922 addressed of newly announced virtual circuit
  210.       ar$tpa - 0; This is what we're looking for
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bradley, Brown                                                  [Page 4]
  227.  
  228. RFC 1293                      Inverse ARP                   January 1992
  229.  
  230.  
  231.    The InARP response will be completed similarly.
  232.  
  233.       ar$hrd - 0x000F the value assigned to Frame Relay
  234.       ar$pro - protocol type for which you are searching
  235.                  (i.e.  IP = 0x0800)
  236.       ar$hln - 2,3, or 4 byte addressing length
  237.       ar$pln - byte length of protocol address for which you
  238.                  are searching (for IP = 4)
  239.       ar$op  - 9; InARP response
  240.       ar$sha - Q.922 address of responding station
  241.       ar$spa - protocol address requested
  242.       ar$tha - Q.922 address of requesting station
  243.       ar$tpa - protocol address of requesting station
  244.  
  245.    Note that the Q.922 addresses specified have the C/R, FECN, BECN, and
  246.    DE bits set to zero.
  247.  
  248.    Procedures for using InARP over a Frame Relay network are identical
  249.    to those for using ARP and RARP discussed in section 10 of the
  250.    Multiprotocol Interconnect over Frame Relay Networks document [3].
  251.  
  252. 8.  References
  253.  
  254.    [1]  Plummer, David C., "An Ethernet Address Resolution Protocol",
  255.         RFC-826, November 1982.
  256.  
  257.    [2]   Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI,
  258.         March 1990.
  259.  
  260.    [3]  Bradley, T., Brown, C., Malis, A.,   "Multiprotocol Interconnect
  261.         over Frame Relay Networks", RFC-1294, January 1992.
  262.  
  263.    [4]  Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution
  264.         Protocol", RFC-903, Stanford University, June 1984.
  265.  
  266.  
  267. 9.  Security Considerations
  268.  
  269.    Security issues are not addressed in this memo.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Bradley, Brown                                                  [Page 5]
  283.  
  284. RFC 1293                      Inverse ARP                   January 1992
  285.  
  286.  
  287. 10.  Authors' Addresses
  288.  
  289.       Terry Bradley
  290.       Wellfleet Communications, Inc.
  291.       15 Crosby Drive
  292.       Bedford, MA  01730
  293.  
  294.       Phone:  (617) 275-2400
  295.  
  296.       Email:  tbradley@wellfleet.com
  297.  
  298.  
  299.       Caralyn Brown
  300.       Wellfleet Communications, Inc.
  301.       15 Crosby Drive
  302.       Bedford, MA  01730
  303.  
  304.       Phone:  (617) 275-2400
  305.  
  306.       Email:  cbrown@wellfleet.com
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Bradley, Brown                                                  [Page 6]
  339.